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Using TSP  With  a  Multi-Disciplined 
Project  Management  System 

Timothy  A.  Chick 
Naval  Air  Warfare  Center 

The  Team  Software  Process™  (TSP™)  provides  an  extraordinary  amount  of  data,  including  project  planning  and  tracking 
data  in  terms  of  task  hours  and  earned  value,  hut  it  does  not  provide  a  mechanism  for  incorporating  the  plans  of  multiple 
teams,  which  do  not  all  use  TSP.  In  today  world  of  brge  and  complex  systems,  the  project  must  consist  of  multiple  disci¬ 
plines  such  as  software  engineers,  system  engineers,  hardware  engineers,  domain  experts,  test  engineers,  and  other  support  per¬ 
sonnel  To  plan  and  track  a  multi-discipline  project,  a  consolidated  plan  must  he  created  and  tracked.  Not  all  disciplines  are 
able  or  willing  to  use  TSP,  so  traditional  project  planning  and  tracking  methods  must  he  used for  the  overall  project. 


Standard  Team  Software  Process™ 
(TSpsM)  for  a  single  project  is  designed 
for  software  teams  of  between  three  and 
15  software  engineers.  TSP  does  not 
address  other  disciplines  or  how  to  inte¬ 
grate  the  plans  and  schedules  of  the  many 
individuals  needed  to  develop,  build,  or 
maintain  a  large  complex  system.  Because 
it  does  not  address  how  to  integrate  the 
plans  and  schedules  of  a  large  system,  it 
also  does  not  address  how  to  manage  or 
track  such  a  large  project. 

This  is  the  dilemma  I  found  myself  in 
a  few  years  ago  when  my  organization 
decided  to  begin  using  TSP  for  its  soft¬ 
ware  work.  In  addition  to  software  engi¬ 
neering,  a  typical  project  for  my  group 
includes  systems  engineering,  indepen¬ 
dent  verification  and  validation,  domain 
expertise,  flight  testing,  and  multiple  sup¬ 
port  functions  such  as  configuration  man¬ 
agement  and  quality  assurance.  Of  all 
these  disciplines,  only  the  software  engi¬ 
neering  group  was  able  or  willing  to  use 
TSP,  so  traditional  project  planning  and 
tracking  methods  were  needed  for  the 
overall  project. 

Why  Have  a  Consolidated 
Plan? 

A  consolidated  plan  forces  the  many  disci¬ 
plines’  practitioners  to  think  through  their 
approach  and  make  decisions  about  how 
to  proceed.  It  forces  the  disciplines’  prac¬ 
titioners  to  think  outside  their  proverbial 
bubbles  and  consider  how  the  work  they 
perform  impacts  other  groups.  Network- 
based  schedules  can  then  be  created  to 
identify  the  interdependencies  of  activities 
and  the  impacts  of  late  or  early  starts. 

Once  the  schedule  is  developed,  a  crit¬ 
ical  path  can  be  identifted  and  what  if  exer¬ 
cises  can  be  performed.  In  addition, 
resources  —  including  facilities,  equipment, 
and  personnel  -  can  be  identified  and 
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tracked.  The  earned  value  (EV)  method 
for  each  task  should  be  determined  during 
the  development  of  the  plan.  The  consol¬ 
idated  plan  win  provide  a  vehicle  to  facili¬ 
tate  executive  and  customer  review.  The 
process  of  developing  a  consolidated  plan 
win  often  identify  missing  work  in  the 
individual  team’s  plans,  thereby  identifying 
potential  problems  early. 

A  consohdated  project  plan  should 
define  how,  when,  by  whom,  and  for  how 
much.  It  should  adequately  reflect  con¬ 
tract  milestones,  estabhsh  meaningful  indi- 

**The  process  of 
developing  a 
consolidated  plan  will 
often  identify  missing 
work  in  the  individual 
team's  plans,  thereby 
identifying  potential 
problems  early/* 


cators  to  measure  work  progress,  and 
ahow  for  the  identiftcation  of  specific 
activities  and  events  that  contribute  to 
schedule  variances.  Without  addressing 
the  interdependencies  of  the  many  disci¬ 
plines,  you  cannot  adequately  address 
these  questions. 

TSP  Versus  Traditional  Project 

Planning  and  Tracking 

TSP  encapsulates  many  of  the  elements  of 
traditional  project  planning  and  tracking 
such  as  work  breakdown  structure  (WBS) 
or  size  summary  (SUMS),  which  is  a  deUv- 
erable-oriented,  hierarchical  decomposi¬ 
tion  of  the  work  to  be  executed  [1].  TSP 


also  addresses  things  like  tasks  and 
resource  allocation  at  a  much  more 
detailed  level  than  most  common  project 
plans.  However,  TSP  does  not  fuUy  encap¬ 
sulate  other  concepts  of  traditional  pro¬ 
ject  planning  and  tracking  such  as  (1) 
resource  dictionaries,  which  include  labor 
category,  rate  (cost/staff  hour),  and 
resource  availability;  (2)  tasks  with  associ¬ 
ated  logic;  (3)  Gantt/Pert  graphs;  and  (4) 
critical  path  analysis.  This  article  will  only 
scratch  the  surface  of  some  of  these  con¬ 
cepts;  for  more  details  refer  to  [1]. 

After  many  years  of  experimenting  and 
using  different  techniques  for  project  plan¬ 
ning  and  tracking,  my  organization  has 
developed  the  following  guidelines  to  con¬ 
sider  when  developing  a  consolidated  plan: 

•  WBS  -  develop  to  two  or  three  levels: 
°  Determine  EV  method. 

■  TSP  tasks  use  percent  complete 
as  defined  in  the  section  “Con¬ 
verting  TSP  EV  Into  EVMS 
EV”  (see  page  6). 

■  Non-TSP  tasks  use  50/50  as 
the  preferred  method;  0/100  is 
only  used  for  tasks  less  than  or 
equal  to  a  one-month  duration 
or  reporting  period. 

■  Work  activities  are  not  to 
exceed  two-month  durations  or 
two  reporting  period  durations. 

°  Tasks  should  be  discrete,  resulting 
in  a  product  or  measurable  result. 

°  Resources  should  be  assigned  with 
budgeted  hours  or  expense. 

•  Limit  level-of-effort  (LOE)  activities 
to  less  than  10  percent  of  total  effort. 

Earned  Value  Management 

EV  is  the  budgeted  value  for  an  element 
of  work  that  has  been  completed,  with 
that  value  determined  from  what  had  ini¬ 
tially  been  planned  for  accomplishing  that 
element  of  work.  EV  techniques  have 
been  developed  to  provide  multiple  ways 
to  measure  accomplishment  that  best  fits 
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the  work  being  accomplished  [2],  TSP 
uses  the  EV  technique  0/100,  which 
allows  no  credit  of  a  given  task  until  the 
task  is  completed.  No  value  is  earned  for 
starting  a  task  or  for  partially  completing  a 
task. 

This  planning  technique  should  be 
limited  to  tasks  that  are  planned  to  start 
and  complete  within  the  same  reporting 
period.  This  method  works  well  using  TSP 
because  TSP  breaks  the  work  task  down 
to  such  granularity  that  a  task  is  complet¬ 
ed  every  week,  which  is  the  reporting  peri¬ 
od  of  a  TSP  team.  A  TSP  team  meets 
weekly  to  discuss  individual  status  and 
how  it  impacts  the  team’s  commitments. 

I  have  found,  however,  that  this 
method  usually  does  not  work  very  well 
for  a  large  complex  project,  which  uses 
traditional  project  planning  and  tracking 
because  developing  such  a  detailed  plan  at 
the  project  level  is  usually  not  realistic.  It  is 
very  difficult  to  break  tasks  down  to 
extremely  small  elements  and  still  be  able 
to  accurately  apply  duration  and  logic 
while  stiU  accounting  for  any  interdepen¬ 
dencies  with  other  disciplines. 

For  example,  many  projects  report  EV 
monthly.  In  this  case,  0/100  would  be  a 
good  method  of  EV  for  tasks  that  are  less 
than  one  month  in  duration.  If  you  used 
0/100  for  tasks  that  had  duration  longer 
than  the  reporting  period,  then  you  would 
have  spikes  in  your  EV.  This  makes  it  very 
difficult  to  determine  if  the  project  is  pro¬ 
gressing  as  planned  or  if  corrective  action 
is  required. 

Other  EV  methods  not  used  by  TSP 
are  50/50,  percent  complete,  and  LOE. 
The  50/ 50  technique  is  typically  used  when 
the  task  begins  in  one  reporting  period  and 
completes  in  the  next.  The  50/50  tech¬ 
nique  credits  50  percent  of  the  EV  when  a 
task  is  started  and  50  percent  of  the  EV 
when  the  task  is  completed.  By  receiving 
EV  for  starting  and  completing  the  task, 
this  method  allows  a  project  to  show 
progress  during  both  reporting  periods. 

The  least  desirable  of  the  discrete  EV 
techniques  is  the  percent-complete  meth¬ 
od.  Percent  complete  allows  an  estimated 
percent  completed  to  be  assigned  for  a 
given  reporting  period.  Unlike  0/100  and 
50/50,  this  method  can  be  extremely  sub¬ 
jective.  For  example,  if  the  estimated  per¬ 
cent  completed  is  based  on  opinion  rather 
than  on  an  objective  evaluation  of  the 
work  completed  and  the  work  remaining, 
then  the  EV  assigned  to  the  task  may  be 
grossly  inaccurate. 

Certain  tasks  are  difficult  to  quantify  in 
terms  of  work  accomplished;  these  tasks 
are  referred  to  as  LOE.  Because  the  EV 
win  always  equal  the  budget,  there  will 


never  be  any  schedule  variance.  This 
method  should  only  be  used  for  tasks  in 
which  no  tangible  product  is  developed 
such  as  project  management,  clerical  sup¬ 
port,  etc.  This  method  would  be  used  for 
many  of  the  off-task  items  identified  in 
TSP  such  as  meetings,  phone  calls,  or  any¬ 
thing  else  not  directly  related  to  the  imme¬ 
diate  activity. 

In  my  experience,  groups  that  are  new 
to  EV  try  to  use  this  method  the  most 
because  it  is  the  easiest  to  define  and  track. 
The  problem  is  that  it  does  not  usually 
give  an  accurate  picture  of  how  the  pro¬ 
ject  is  progressing.  In  fact,  when  LOE  is 
greater  than  10  percent  of  total  effort,  the 
EV  becomes  skewed  to  the  point  that  it  is 
very  difficult  to  determine  if  the  project  is 
on  schedule  or  on  cost,  and  if  the  project 
will  be  able  to  make  its  commitments. 

Developing  a  Project’s  EV 
Management  System  With 
TSP  as  an  Input 

Now  that  I  have  gone  over  why  a  consoli¬ 
dated  plan  is  needed  and  some  of  the  dif¬ 
ferences  between  TSP  and  traditional  pro¬ 
ject  planning  and  tracking,  how  do  you 
make  the  leap  from  a  TSP  launch  to  a  con¬ 
solidated  project  EV  management  system 
(EVMS)? 

The  TSP  launch  provides  most  of  the 
core  data  elements  needed  as  input  into  a 
consolidated  EVMS.  It  provides  estimates, 
tasks  to  be  performed,  durations,  sequen¬ 
tial  logic  and  milestones,  and  assigns 
resources  to  tasks.  The  data  hours  found 
in  TSP  are  the  task  hours  that  resources  will 
acmally  work  to  complete  the  task  identi¬ 
fied  in  TSP.  The  EVMS  system  captures 
staff  hours,  which  are  all  of  the  hours  the 
resources  work  in  each  period.  Therefore, 
a  conversion  of  the  data  is  necessary.  The 
EVMS  system  also  needs  to  capture  inter¬ 
dependencies  in  more  detail  than  identi¬ 
fied  using  TSP. 

As  stated  previously,  TSP  breaks  its 
major  tasks  down  into  granular  tasks  that 
can  be  completed  within  a  one -week  peri¬ 
od.  This  can  be  considered  too  much 
detail  to  maintain  in  a  consolidated  project 
plan.  So  translation  between  a  TSP  task 
and  an  EVMS  activity  is  done  by  translat¬ 
ing  SUMS  assembly  items  to  activities  in 
EVMS.  The  resources  are  then  assigned  to 
the  EVMS  activities  by  determining  the 
resources  assigned  to  the  corresponding 
TSP  tasks. 

The  task  hours  planned  for  the  SUMS 
assembly  items  must  be  converted  into 
staff  hours.  When  we  first  made  this  con¬ 
version,  we  did  what  any  good  planner 
does  when  he  or  she  has  no  historical  data: 


We  estimated  based  on  personal  experi¬ 
ence.  We  knew  the  average  task  hours  per 
week  the  TSP  team  used  for  estimation, 
and  we  knew  the  average  hours  per  week 
an  engineer  worked,  thus  giving  us  a  start¬ 
ing  ratio  for  task  hours  to  staff  hours. 
Once  we  collected  some  historical  data, 
we  determined  that  based  on  the  type  of 
work  being  performed,  the  task  hour  to 
staff  hour  ratio  varies  between  2.0  and 
2.62.  That  is,  it  takes  between  2.0  and  2.62 
staff  hours  for  every  TSP  task  hour  per¬ 
formed.  Knowing  this,  we  accurately  con¬ 
verted  task  hours  planned  during  a  TSP 
launch  to  staff  hours  for  EVMS  purposes. 
Once  the  estimated  staff  hours  were 
determined,  we  used  the  resource  hourly 
rates  to  develop  cost  estimates. 

The  duration  of  EVMS  activities  can 
be  determined  by  using  the  start  and  com¬ 
pletion  date  of  the  first  and  last  phase 
mapped  to  the  TSP  assembly.  EVMS  mile¬ 
stones  are  updated  based  on  any  mile¬ 
stones  identified  during  the  TSP  launch, 
along  with  milestones  identified  from 
other  project  entities. 

Using  the  task  log  in  Table  1  (see  next 
page)  as  an  example,  one  of  the  activities 
in  EVMS  is  called  Widget  A.  Jack,  John, 
and  Jill  are  assigned  resources  for  Widget 
A.  According  to  the  task  log.  Jack  is 
assigned  200  planned  task  hours,  and  John 
and  Jill  are  both  assigned  44  planned  task 
hours.  Using  the  TSP  task  hour  to  staff 
hour  ratio  of  2.62,  Jack  would  be  assigned 
524  (200*2.62)  staff  hours,  and  John  and 
Jill  would  be  assigned  115  (44*2.62)  staff 
hours  in  EVMS  for  Widget  A.  The  dura¬ 
tion  for  Widget  A  in  the  EVMS  would  be 
95  days  because  the  planned  start  week 
and  completion  date  is  week  5  and  week 
24,  respectively  ((24  weeks  minus  5 
weeks)*5  days/week  =  95  days).  The  pre¬ 
decessor  of  Widget  A  would  be  Widget  B, 
and  the  successor  of  Widget  A  would  be 
Widget  C  because  of  the  order  established 
during  the  TSP  launch. 

Once  the  conversion  of  TSP  launch 
data  to  EVMS  data  is  done,  additional 
analysis  needs  to  be  made  of  the  project’s 
consolidated  plan  before  it  is  considered 
complete.  TSP  off-task  activities  need  to 
be  identified  and  budgeted  in  the  EVMS 
system.  This  includes  TSP  roles  such  as 
planning  manager,  test  manager,  design 
manager,  and  team  lead.  These  tasks 
should  be  as  specific  as  possible  so  that  the 
correct  method  of  EV  can  be  assigned, 
trying  to  avoid  LOE  activities  as  much  as 
possible  so  that  project  LOE  does  not 
exceed  10  percent  of  the  total  effort. 

Dependencies  between  the  TSP  team’s 
activities  and  other  disciplines  should  be 
identified  and  linked  in  the  EVMS.  This 
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allows  for  the  establishment  of  the  pro¬ 
ject’s  critical  path.  The  dependencies 
should  also  be  analyzed  to  determine  the 
impact  to  the  other  disciplines’  plans,  and 
to  determine  any  resource  allocations  such 
as  facilities’  needs  to  be  changed.  Once 
this  additional  analysis  is  completed,  the 
consolidated  plan  is  ready  to  be  baselined. 
The  baseline  is  the  basis  in  which  the  pro¬ 
ject’s  performance  is  measured  against 
using  EV. 

At  this  point,  you  may  be  thinking  it  is 
a  lot  of  work  to  baseline  a  consolidated 
project  plan  -  and  you  would  be  correct. 
In  fact,  most  large  projects  only  rebaseUne 
once  or  twice  a  year  and  only  if  the  pro¬ 
jects’  overall  performance  against  the 
baseline  varies  so  much  that  the  plan  no 
longer  reflects  reality  sufficiently  to  man¬ 
age  the  project.  So  how  do  you  take  into 
account  that  TSP  teams  usually  relaunch 
every  three  to  four  months? 

This  method  required  that  the  TSP 
team  plan  the  entire  effort  up  front,  even 
if  the  effort  is  over  a  year  in  duration. 
When  TSP  teams  relaunch,  the  current 
plan  in  the  EVMS  is  updated  but  not  the 
baseline.  The  only  time  the  EVMS  base¬ 
line  will  be  updated  with  a  team’s  relaunch 
data  is  when  the  entire  project  undergoes 
a  project  rebaseUne. 

During  the  period  that  the  EVMS  base- 
Une  does  not  reflect  the  TSP  team’s 
relaunch,  the  TSP  relaunch  data  wUl  be  used 
as  the  basis  for  any  EVMS  action  plans 
developed  due  to  a  deviation  outside  the 
project’s  defined  acceptable  variance,  usual¬ 
ly  plus  or  minus  10  percent  cost  and  sched¬ 
ule.  In  other  words,  a  relaunch  is  simply  a 


mechanism  for  developing  a  detailed  action 
plan  for  correcting  inaccurate  plans  devel¬ 
oped  during  a  TSP  team’s  initial  launch. 

It  is  important  to  note  that  even 
though  the  overall  team  plan  may  extend 
for  several  years,  the  TSP’s  detailed  plans 
extend  for  only  a  few  months  [3] .  Thus,  it 
should  be  expected  that  once  the  TSP 
team  goes  beyond  the  first  few  months 
following  the  TSP  launch,  the  team  wiU 
begin  to  vary  beyond  the  EVMS  baseUne 
due  to  the  fact  that  TSP  launches  and 
relaunches  are  not  designed  to  develop  a 
detailed  plan  beyond  a  three-  to  four- 
month  period. 

For  example.  Figure  1  represents  the 
consoUdated  EV  for  a  multi-discipUned 
project  that  consists  of  four  TSP  teams  - 
system  engineers,  hardware  engineers, 
domain  experts,  test  engineers  —  and  other 
support  personnel.  Figure  1  shows  that 
both  the  cost  and  schedule  are  within  a  10 
percent  variance,  thus  the  project  is  per¬ 
forming  within  expected  parameters. 

Figure  2  is  an  EVMS  report  generated 
at  the  TSP  Team  A  level  of  the  multi-dis¬ 
ciplined  WBS.  It  shows  that  TSP  Team  A 
is  behind  schedule  by  1 1  percent  and  over 
budget  by  49  percent  when  comparing  the 
team’s  current  status  against  its  baseline 
plan.  Because  this  team  is  outside  the  10 
percent  cost  and  schedule  thresholds,  the 
team  is  required  to  develop  an  action  plan 
on  how  it  will  address  these  variances. 
One  way  for  the  team  to  address  these 
variances  is  to  conduct  a  relaunch,  which 
would  provide  very  detailed  plans.  Both 
the  TSP  team  and  project  management 
can  then  use  these  detailed  plans  to  medi¬ 


ate  the  impact  to  the  overall  project. 
Because  the  project  is  performing  well, 
based  on  Figure  1,  TSP  Team  As  perfor¬ 
mance  would  not  justify  the  expense  or 
effort  needed  to  rebaseline  the  entire 
multi-discipline  project.  Thus,  for  EVMS 
purposes,  TSP  Team  A  would  be  tracked 
against  its  action  plan. 

Converting  TSP  EV  Into 
EVMS  EV 

TSP  teams  can  use  a  modified  percent- 
complete  method  when  converting  TSP 
EV  into  EVMS  EV.  I  mentioned  earlier 
that  percent  complete  could  be  subjec¬ 
tive  due  to  the  lack  of  unbiased  judg¬ 
ment.  In  this  case,  because  TSP  tasks  are 
at  a  more  granular  level  than  the  EVMS 
activities,  the  TSP  tasks  become  the 
unbiased  element  used  to  determine  per¬ 
cent  complete. 

One  way  of  updating  the  completion 
of  a  TSP  task  is  using  the  percent-com¬ 
plete  method,  which  is  assigned  to  the 
EVMS  activity  proportionally  to  the  total 
number  of  unique  TSP  tasks  mapped  to 
the  TSP  assembly.  For  example,  if  five 
unique  tasks  are  mapped  to  Assembly  A 
and  two  of  the  tasks  have  been  complet¬ 
ed,  then  Activity  A,  in  the  EVMS,  would 
be  40  percent  complete.  Some  TSP  tools 
such  as  Process  Dashboard  automatically 
calculate  the  percent  complete  at  a  given 
assembly  level,  in  which  case  the  number 
would  be  the  percent  complete  in  the 
EVMS  for  the  corresponding  activity. 

Actual  cost  and  actual  staff  hours 
expended  on  an  activity  in  the  EVMS 
should  be  recorded  using  a  timecard  sys- 


Table  1 :  TSP  Task  Log 


Assembly 

Phase 

Task 

Resources 

Estimated  Size  | 

Size  Measure  | 

Rate  1 

(per  hour)  1 

Estimated  1 

Hours  1 

Engineers  | 

Plan  Hours  | 

Plan  Date 

o 

0) 

5 

C 

n 

Q. 

Widget  B 

PM 

Widget  B  -  Post-mortem 

Jack 

3 

LOC 

8.3 

0.4 

1.0 

0.4 

7/19/2004 

5 

Widget  A 

PLAN 

Widget  A  -  Research  and  Planning 

Jack 

2,000 

LOC 

200.0 

10.0 

1.0 

10.0 

7/19/2004 

5 

Widget  A 

OLD 

Widget  A  -  Detailed  Design 

Jack 

2,000 

LOC 

47.6 

42.0 

1.0 

42.0 

8/23/2004 

10 

Widget  A 

TD 

Widget  A  -  Test  Development 

Jack 

2,000 

LOC 

200.0 

10.0 

1.0 

10.0 

9/6/2004 

12 

Widget  A 

DLDR 

Widget  A  -  DLD  Review 

Jack 

2,000 

LOC 

125.0 

16.0 

1.0 

16.0 

9/13/2004 

13 

Widget  A 

DLDINSP 

Widget  A  -  DLD  Inspection 

Jack,  John,  Jill 

2,000 

LOC 

90.9 

22.0 

1.0 

22.0 

9/27/2004 

15 

Widget  A 

CODE 

Widget  A  -  Code 

Jack 

2,000 

LOC 

47.6 

42.0 

1.0 

42.0 

10/25/2004 

19 

Widget  A 

CR 

Widget  A  -  Code  Review 

Jack 

2,000, 

LOC 

153.8 

13.0 

1.0 

13.0 

11/1/2004 

20 

Widget  A 

COMPILE 

Widget  A  -  Compile 

Jack 

2,000 

LOC 

400.0 

5.0 

1.0 

5.0 

11/1/2004 

20 

Widget  A 

CODEINSP 

Widget  A  -  Code  Inspection 

Jack,  John,  Jill 

2,000, 

LOC 

90.9 

22.0 

1.0 

22.0 

11/15/2004 

22 

Widget  A 

UT 

Widget  A  -  Unit  Test 

Jack 

2,000 

LOC 

125.0 

16.0 

1.0 

16.0 

11/29/2004 

24 

Widget  A 

PM 

Widget  A  -  Post-mortem 

Jack 

2,000 

LOC 

1000.0 

2.0 

1.0 

2.0 

11/29/2004 

24 

Widget  C 

PLAN 

Widget  C  -  Research  and  Planning 

Jack 

400 

LOC 

200.0 

2.0 

1.0 

2.0 

11/29/2004 

24 

Note:  For  DLDINSP  and  CODEINSP,  the  number  of  engineers  is  listed  as  1 .0.  This  is  due  to  the  replication  of  task  that  occurs  using  the  Software  Engineering  Institute’s  TSP  tool.  This  is  only  one  of  many 
equally  valid  methods  used  to  address  the  replication  of  tasks  to  multiple  individual  workbooks  when  multiple  engineers  are  assigned  as  a  resource. 
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Figure  1:  Project  Summary  EVMS  Report 


tern  or  other  mechanism  and  not  by  using 
the  task  hour  to  staff  hour  ratio.  This  con¬ 
version  should  only  be  used  for  planning 
purposes.  Both  TSP  and  non-TSP  teams 
need  to  collect  these  actual  staff  hours 
expended  In  the  same  manner  to  maintain 
consistency  and  validity  of  EVMS  data. 

Conclusion 

TSP  allows  software  teams  to  consistently 
meet  commitments  [4].  TSP  provides  an 
extraordinary  amount  of  data  that  can  be 
used  for  project  planning  and  tracking. 
This  data  can  be  effectively  Incorporated 
Into  a  consolidated  multi-disciplined  pro¬ 
ject  plan.  By  incorporating  the  TSP  data 
into  an  EVMS  that  tracks  the  entire  pro¬ 
ject  and  not  just  the  software  development 
effort,  the  project  Is  able  to  consider  how 
work  performance  by  one  group  impacts 
other  groups  within  the  project. 

TSP  encapsulates  many  traditional  pro¬ 
ject  planning  and  tracking  elements  such  as 
WBS,  tasks,  and  resource  allocation.  TSP 
does  not  fuUy  encapsulate  other  concepts 
of  traditional  project  planning  and  track¬ 
ing  such  as  critical  path  and  dependencies. 

TSP  uses  the  0/100  method  of  EV. 
Other  EV  methods  not  used  by  TSP 
include  50/50,  percent  complete,  and 
LOE.  It  is  important  to  select  the  appro¬ 
priate  method  of  EV  to  accurately  mea¬ 
sure  the  performance  of  an  activity.  When 
selecting  an  EV  method  for  a  project, 
duration  and  type  of  activity  are  the  pri¬ 
mary  considerations. 

Most  of  the  information  required  to 
develop  an  EVMS  project  plan  can  be 
obtained  from  a  TSP  launch.  In  addition  to 
this  data,  you  must  consider  TSP  off-task 
activities  (LOE),  dependencies  between 
the  TSP  team’s  activities  and  other  disci¬ 
plines,  and  the  project’s  critical  path. 

For  project  tracking  purposes,  once  the 
TSP  data  has  been  incorporated  into  the 
EVMS  project  baseline,  a  TSP  team  can 
use  a  modified  percent-complete  method 
when  converting  TSP  EV  into  EVMS  EV. 
Because  TSP  tasks  are  at  a  more  granular 
level  then  the  EVMS  activities,  the  TSP 
tasks  become  an  unbiased  element  used  to 
determine  percent  complete. 

Most  large  projects  only  rebaseline  the 
project  plan  once  or  twice  a  year,  or  when 
the  project’s  overall  performance  against 
the  baseline  varies  so  much  that  the  plan 
no  longer  reflects  reality.  Including  the 
entire  software  effort  in  the  EVMS  base¬ 
line  requires  that  the  TSP  team  launch  the 
entire  effort  —  not  just  the  next  three-  to 
four-month  effort.  For  EVMS,  a  TSP 
relaunch  Is  used  simply  as  a  mechanism 
for  developing  a  detailed  action  plan  for 
correcting  inaccurate  plans  developed  dur¬ 


ing  a  TSP  team’s  initial  launch  or  during 
the  initial  EVMS  baseline. 

TSP  does  not  eliminate  the  need  for 
developing  a  consolidated  project  plan 
and  tracking  progress  against  the  plan, 
especially  in  the  world  of  very  large  and 
complex  systems  that  consist  of  personnel 
from  multiple  disciplines  such  as  software 
engineering,  system  engineering,  hardware 
engineering,  domain  expertise,  test  engi¬ 
neering,  and  other  support  personnel. 
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